home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19960715-19961006 / 000083_news@columbia.edu _Sat Jul 27 11:06:58 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  8KB

  1. Return-Path: news@columbia.edu
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id LAA17124 for <kermit.misc@watsun.cc.columbia.edu>; Sat, 27 Jul 1996 11:06:57 -0400 (EDT)
  3. Received: (from news@localhost) by newsmaster.cc.columbia.edu (8.7.5/8.7.3) id LAA16695 for kermit.misc@watsun; Sat, 27 Jul 1996 11:06:56 -0400 (EDT)
  4. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  5. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  6. Newsgroups: comp.protocols.kermit.misc,comp.dcom.modems
  7. Subject: Re: Problem getting 28800 bps in C-Kermit 5A(190) on a v.34 internal
  8. Date: 27 Jul 1996 15:06:32 GMT
  9. Organization: Columbia University
  10. Lines: 151
  11. Message-ID: <4tdb9o$p4o@apakabar.cc.columbia.edu>
  12. References: <CROTEN.96Jul24005129@crl.crl.com> <4t63nh$imc@samba.rahul.net> <CROTEN.96Jul27005455@crl.crl.com>
  13. NNTP-Posting-Host: watsun.cc.columbia.edu
  14. Xref: news.columbia.edu comp.protocols.kermit.misc:5656 comp.dcom.modems:145799
  15.  
  16. In article <CROTEN.96Jul27005455@crl.crl.com>,
  17. Charles Roten <croten@crl.crl.com> wrote:
  18. : Sorry, Clarence .. I added ',comp.dcom.modems' to the '^Followup-To: ' and 
  19. : '^Newsgroups: ' lines again, due to the presence of some modem-chipset 
  20. : related issues.  Since _both_ you _and_ Frank Da Cruz warned me about the 
  21. : "Rockwell RPI" chipset problems, I decided to take you _both_ seriously 
  22. : about this issue.  Though I still am not sure whether my modem has this 
  23. : problem or not .. and indeed had never heard of it until your responses to 
  24. : my earlier post.  
  25. See item 20 of the Kermit FAQ:
  26.  
  27.   http://www.columbia.edu/kermit/faq.html
  28.   ftp://kermit.columbia.edu/kermit/faq.txt
  29.  
  30. : BTW, are there any diagnostics for this problem, other than the one Clarence 
  31. : Dold alludes to below ??
  32. :
  33. In general, the modem-specific command to enable error correction or data
  34. compression results in an ERROR response.  Also I think the product ID shown
  35. by ATI3 should say RPI in it somewhere.  But none of this is universal; every
  36. modem is different.
  37.  
  38. : BTW, Frank Da Cruz _seems_ to imply _none_ of these mods are neccessary in 
  39. : order to enable "fullscreen" display on a SunOS 4 box.  Maybe I went off 
  40. : on an unneccessary tangent here ??  
  41. Correct.
  42.  
  43. : But there _does_ seem to be a problem here, perhaps with interaction with 
  44. : the antique windowing system (Sunview) my box uses.  _Any_ interaction 
  45. : between any ovelapping window _or_ Sunview itself (such as closing the 
  46. : window in which I use C-Kermit) and the "vttool" vt100 emulation window I am 
  47. : (now) using as a C-Kermit terminal emulation front end can "freeze" Suntools 
  48. : _totally_ for minutes to hours.  The only way of breaking out _by_ _choice_ 
  49. : seems to be a system reboot.  Ugly.  
  50. Not a Kermit problem.  The fullscreen file transfer display works fine on
  51. hundreds of different UNIX platforms.  It uses standard curses library calls.
  52. On some platforms there are bugs in the curses library (typical symptom: it
  53. works the first time, does not work subsequent times).  In other situations
  54. there can be bugs in the terminal emulator or windowing system through which
  55. you view it.  Or (but probably not in your case) a simple mismatch between the
  56. type of terminal curses thinks you have (look at your UNIX TERM variable) and
  57. the type you actually do have.
  58.  
  59. : Hmm .. no problem seen so far with 19200 .. except an apparent inability to 
  60. : get above that throughput except fleetingly and temporarily during downloads 
  61. : where _overall_ efficiency is rated by "stat" right at 50% (or a hair under) 
  62. : for a _38400_ _bps_ connection.  I would expect 60-66% if I were receiving 
  63. : at 28800 bps, of course.  
  64. How do you know the connection is really at 28800 bps?  Did the modem say so
  65. in its CONNECT message?  How do you know the connection *stayed* at 28800 bps?
  66. V.34 modems can shift down (and hopefully) back up at any time during the
  67. connection, perhaps repeatedly.
  68.  
  69. : >Do you get a "CONNECT xxx00, LAP-M" or something like that?
  70. : Nope .. just "CONNECT 38400".  No ", LAP-M" suffix at all.  
  71. Sounds like you don't have an error-corrected connection.  That could be
  72. because your modem doesn't *do* error correction, or because it does, but the
  73. other one doesn't, or because they both do, but nevertheless failed to
  74. negotiate a common error correction protocol.  Or it could simply be that you
  75. have configured the modem not to issue protocol messages in its result codes.
  76. Look in your modem manual at the X command (X1, X4, etc)...
  77.  
  78. : set line /dev/ttym1
  79. : set incomplete keep
  80. : set flow rts/cts
  81. : set speed 38400
  82. : set dial speed-matching off
  83. : set parity none
  84. : set send packet-length 9000       <-- Not needed, see manual
  85. : set receive packet-length 9000    <-- This might be overkill
  86. : set window 1                      <-- See below
  87. : ...
  88. : Another problem I get from this combination of C-Kermit, terminal emulator, 
  89. : and windowing system on my box is the (quite sudden) interruption of a file 
  90. : transmission with the "too many NAKs" complaint from C-Kermit.  
  91. Try using a shorter packet length and a bigger window size.  For example:
  92.  
  93.   set window 4
  94.   set receive packet-length 1000
  95.  
  96. Given the uncertainties about your modem, you certainly don't want to stress
  97. it with 9000-byte packets until after you have achieved satisfactory results
  98. with more conservative settings.  The rule is:
  99.  
  100.  1. Get it working reliably
  101.  2. Then vary the packet and window sizes until optimum throughput is achieved
  102.  3. Then (maybe) add some control-character unprefixing
  103.  
  104. See the Kermit FAQ for a longer explanation.
  105.  
  106. : Could this be an artifact of the fact that these file transmissions are 
  107. : from a host in California (crl.com) which mounts C-kermit, _through_ _a_ 
  108. : _telnet_ _connection_ _from_ _an_ _intermediate_ _host_ (a local Seattle-
  109. : based ISP .. crl.com has no Seattle POP), to my local UNIX box ?  
  110. : Yeah, I know .. a wierd way to do things ..  
  111. Yes, of course that will slow things down.  And although you did not say
  112. anything above about control-character unprefixing, I should warn you that if
  113. you start unprefixing control characters to get more performance (which you
  114. can read about in our FAQ and in the online C-Kermit documentation), take
  115. care not to unprefix Telnet's escape character, or the character 255, or
  116. carriage return.  (Of course, none of these are unprefixed by default.)
  117.  
  118. : Owing to the fact that I am not _sure_ of binary file transmission accuracy
  119. : in this "relayed" mode, I uuencode any file which even I _suspect_ of
  120. : containing non-printable characters.  Then, when the "too many NAKs" bug
  121. : shuts me down, I can use UNIX "split", fore and aft, on the (uuencoded)
  122. : file, throwing away the last line or two on the receiving box and the lines
  123. : before that on the one sending.
  124. :
  125. You don't need to do any of this.  Kermit itself acts like a "uuencode"
  126. program to ensure that binary data gets through even the toughest kinds of
  127. links.  Just use the defaults.  If the transfer through your intermediate
  128. Telnet program doesn't work, that means you don't have an 8-bit Telnet
  129. connection, in which case simply tell the sending Kermit to:
  130.  
  131.   set parity space
  132.  
  133. and then it will work.
  134.  
  135. Should the transfer fail partway through, use the built-in recovery feature
  136. (the RESEND command).  Read about it in the online documentation that comes
  137. with C-Kermit.
  138.  
  139. : I'll try out the effect of 'set dial speed-matching off' in my .kermrc later
  140. : this evening.  Thanks.  I just hope it helps throughput, but I don't hold
  141. : out much hope of it assisting the fragility of Sunview in the presence of an
  142. : ongoing C-Kermit download in a vttool window.
  143. Sunview and vttool are problematic only in their response to the curses
  144. display.  To avoid problems, just use some other form of display:
  145.  
  146.   set file display crt
  147.   set file display serial
  148.   set file display none
  149.  
  150. Curses itself on SunOS is fine.  If you use some other terminal or emulator
  151. with SunOS C-Kermit there are no problems at all with the display.
  152.  
  153. Again, please consult the manual "Using C-Kermit", plus the accompanying
  154. online documentation, and our FAQ to save yourself lots of trouble.
  155.  
  156. - Frank